I thought I had seen a similar post in the past, but couldn't find it in the archives... so sorry if this has already been discussed before.

Anyway, today when I got in my car to leave work, my EMPEG failed to boot and displayed a message similar to "No Hard Drive Found, Contact Support".

Needless to say, this scared me.... so I quickly reseated the player and then everything was fine. This seemed pretty fatal initially and I had not expected a player reseat to fix this, so I didn't carefully note the full text of the message. This is first time I have seen anything like this on my player.

I am running 2.00 beta3 with two 20G drives. It was about 52 deg F when this happened. The player had been sitting out in the car for about 3 hours.... so it was probably at about the same temp. I believe this is within the recommended operating range (should be okay down to 5 deg C right?).

I was thinking it might be a sign of marginal drive or something, but it seems odd that both hard drives would have a transient problem at the same time.... unless one was doing something that would keep the EMPEG from finding the other... or if this message comes up if only the first drive fails to respond, etc.

Anyone seen anything like this? And thoughts as to what I should be checking? My first thought when this happened was that a drive jumper may have fallen off.... but when it worked after reseating it, I was perplexed.

If no one has any ideas, I'll be emailing support next.

Thanks!

Okay... just saw the other post I was unable to find before using the BBS 'seach' function.... (I was searching for 'hard drive' not 'hdd' as used in the thread).

Anyway, I saw the recommendations to check the hd cable and jumpers in that thread. It does seem odd that something loose would have caused this since all I did to get it out of this state was pull the player out about an inch and reseat it - but who knows. Actually starting to fear that I have a hard drive problem.(even though both drives have been replaced under warranty a few months of ago). I have another problem that may or may not be related where the player pauses and sometimes locks ups when the drive icon comes up - but I was hoping that was a 2.00 issue (I have seen other posts about this problem with 2.00). I only mention this as it seems to occur fairly often (usually at least once everytime I use the player).

This player came back with a new warranty seal when the mainboard was replaced a few months ago under warranty (memory problem) and I didn't want to break it. However, I think my warranty on the original player just ended last month anyway ... but I have to double check before breaking the seal.

Still open to any suggestions if there is anything I can check without opening it up.

I have a similar issue when my player is cold. Instead of that message I get "failed to unmask ide".

It appears that is the player has been sitting in the cold (i.e. the foot well of my car) the hard disk doesn't spin up either properly or quickly enough the first time. Power cycling the unit solves it.

This is beginning to sound mor and more like a kernel timout issue during boot. We had this before with an earlier kernel prior to 1.0, and my dual-disk system used to cause problems until Mike stretched timeouts somewhat. The "None" announcements for playlists in the main menu is an old friend of mine

Don't forget the kernel itself is in FLASH, and it is booted and ready far faster than a mechanical component like a disk. What surprises me is that there is no decent timeout mechanism in Linux for disks that spin up slowly; this shows how Linux has developed - it has been always assumed that the boot device is the disk itself, which will be up to speed before any bootloader for the kernel becomes active. I am not sure what software is being used for directory mounting (mount? mnt?) but it does seem to be pretty intolerant. Either that or the player itself is expecting a mounted partition when it starts, and doesn't like to get "I'm still waiting" messages back from the mnt/mount sysreq.

It would be interesting to see what disk models and combinations are present in machines showing these boot problems - I bet a number of them are dual-disk.

Mine is single disk.

When I raised the problem with support they asked me if I was using a third party kernel, which I am (mlord's Hijack kernel). They recon that the problem is being caused by mlord's stuff masking irqs for longer than the standard kernel.

I have my suspicions that if I didn't have mlord's kernel installed I would probably see the "no harddrives contact support" message instead of the "failed to unmask ide" message...

Anyway, it's not a significant problem from my point of view.

Okay, I guess I am not as concerned about this problem now as I was a few days ago. I was just initially concerned it was a sign that my hard drive was going out.

Since my original post, this has happened three more times.... but I got the seemingly more common 'Failed to unmask IDE' message every time. This shows as the last line on the boot up screen before it halts, where as the hard drive message was a fresh screen with only the error text in a larger font (looked fairly severe:).

It is odd that I got the hard drive message the first time and the IDE error every subsequent time. I haven't changed anything on the player - haven't even done a sync since the first hard drive error message. Probably some low level OS thing that I could never hope to truly understand :).

Thanks for the reassurance!

Could just be a dodgy cable?

In reply to:

---

When I raised the problem with support they asked me if I was using a third party kernel, which I am (mlord's Hijack kernel). They recon that the problem is being caused by mlord's stuff masking irqs for longer than the standard kernel.

---

Bull-pucky.

I wrote the code in the "standard" kernel, too (which has been augmented by the nice folks at Empeg), and can confidently ensure that the "hijack" kernels don't affect disk detection in the slightest.

The difficulty with IDE drive detection, is that the resets occur serially: first the master drive starts up, and it WAITS for the slave drive. Many manufacturers don't implement the protocol exactly the same way, and so sometimes the master/slave sync fails. Reversing the drive jumpers often cures this (change master to slave, and viceversa). But also, the ATA specs say that either drive can take up to 30 seconds to respond, if needed. Nobody but nobody really wants a Linux kernel to hang around for 60 seconds waiting for IDE startup...

Cheers

Mark Lord
Linux IDE Author

I don't think that's what support meant to say, if they told you that - but basically, if a user has any problems on a nonstandard kernel, they have to apply a normal upgrade (if at all possible) and re-test.

We can't support kernels that might have strange stuff (eg, single drive patches, etc) - it increases the support burden hugely.

Hugo

What David said exactly is:

"It's likely that one of these is causing problems. The hijack enables lots
of things to be done with IRQs and such, so may be causing problems."

(by these he was refering to Hijack and DisplayServer)

So I will remove Hijack for a couple of days and get my empeg cold again...

Hmmm.... noted the following reported on the serial port during startup after resyncing today... is this what would be expected when the IDE HD detection problem occurs (the one described in this thread)?

ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda4 is mounted.
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
ext2fs_check_if_mount: No such file or directory while determining whether /dev/hdc4 is mounted.
empeg-car 2.00-beta3 2001/10/17.

Unfortunately, I had rebooted the player before I went back and checked the startup log so I don't know what state the player was in (normal, or displaying IDE/no HD message)... After a number of restarts, I could not get this error again on the serial port (at least not yet).

No, those messages are normal; we don't run with an /etc/mtab (because that partition is read only) and fsck.ext2 is looking for one.

*Don't* 'fix' it by symlinking to /proc/mounts, this breaks other stuff :)

Hugo

*Don't* 'fix' it by symlinking (/etc/fstab) to /proc/mounts, this breaks other stuff :)

Yeah, and I would still like to know what is broken by that fix and why. fsck surely is happy about that fix, but other parts of the player's software system aren't. I just can't remember which and how that expressed itself. This problem really bugs me because of different things, the "df" command being one of them.

cu,
sven

df will work fine, you just have to specify the filesystem - eg, df /drive0

I can't remember what broke because of that; I think it's something to do with mount/remount stuff...

Hugo

Without having looked at it at all (in other words, by taking a wild guess), I imagine it has something to do with not having all the mount options in /proc/mounts. The Linux guys really need to fix this problem. On the other hand, have you guys ever considered making /etc a (separate) writable filesystem? Or linking /etc/mtab to a file in another writable filesystem?

Here's a thread which explains the phenomenon and even has a little alias for df which supposedly makes things work well without having to symlink to /proc/mounts.

The "Linux Guys" already have fixed it, in the 2.4.xx kernels.

-ml

Ahh. That's what I get for straying from the fold.

df will work fine, you just have to specify the filesystem - eg, df /drive0

Almost, you have to specify the partition, not the mount point.

I can't remember what broke because of that; I think it's something to do with mount/remount stuff...

Might be, I will check that out again as soon as I get a chance.

cu,
sven

Well, df /drive0 works for me.

Hugo

Hi.

Hmm, it didn't work that way last time I tried, but maybe there was a different reason for that. Can't remember the exact circumstances.

cu,
sven

Actually, the manpage says "df displays the amount of disk space available on the filesystem containing each file name argument" - so even df /drive0/fids/100 is valid.

In the second paragraph it mentions that you can point it at a device node, but this isn't the usual use; eg, I usually use "df ." to check the space on the disk with my homedir.

Hugo